

PU2.1 - The problem here is SDLC mapping to Token Ring. I'm not sure but
believe the XIDS are different and if passed through would be CV22'd. I
forgot which bits are different, but think it is in the dlc dependent area.
But, if APPN is in the same box, do you really need DLS support? Let the
PU2.1 be controlled directly by APPN rather than DLS. Also an SDLC
device, mapped to a token ring mac/sap can't handle being a member of a
connection network.

From: [email-masked] (Paul Gacek)
Date: Mon, 3 May 93 07:44:00 PDT
Message-Id: <[email-masked]>

>>2. PU 2.1 Support
>DLS provides a data link connection which can be, and is, used for T2.1
>traffic.  Are you asking for DLS to be supported on additional T2.1
>platforms, such as the AS/400 and OS/2?  That would be product requirements,
>not architectural enhancements.
>
No I am not asking for DLS support on AS/400s or OS/2. While DLS
provides a data link connection it does so by terminating the the DLC
(LLC2 or SLDC)  connection at the DLS router. The 2.1 support issue
is related to handling XID3.

>>    b) SDLC up stream
>This seems reasonable.  It is somewhat strange that this is not provided
>considering that being a secondary SDLC station is substantially simpler to
>implement than being a primary SDLC station.
>
I assume you are talking about the 6611 implementation which as you point
out is a product detail. While I agree secondary SDLC is easier  than primary
SDLC and therefore should "fall out" of any primary implementation, I
believe the 6611 only supports primary SDLC at present. End to end SDLC
is one way of supporting PU1 SDLC devices (the alternative involves LU 6.2).

One SDLC end to end issue is handling of TESTs.

>Since a router using DLS would presumeably deliver multiple logical link
>connections to a single SDLC up stream (host) connection, it would seem to
>me important that the up-stream connection support the group poll capability
>already demonstrated on the 3174 token-ring gateway.  That would, in turn,
>imply that the SDLC down-stream (terminal) support should be capable of
>group polling an attached device.  That would require IBM releasing
>additional documentation on how that protocol works.
>
Group poll - seems like a good idea but isn't this an implementation specific detail.

>>    c) channel
>This could mean a couple of things:
>
>A TCP/IP connection being delivered over a channel to DLS support in the
>mainframe TCP/IP software (FAL/HAL).  That seems to me to be a product
>requirement, rather than an architectural enhancement.
>
I was thinking more of channel connectivity from an SNA DLC standpoint.
TCP connectivity to a mainframe over channel might be an area that BNR and
NSC are interested in pursuing.

>A DLS connection being terminated in a channel attached router which then
>communicates with the mainframe appearing as one of: a 3172 terminating an
>LLC2 LAN connection, a 3174 T2[.1], or a 3745 T4.
>

Something along the lines of 3172 functionality. Channel connectivity up to
the mainframe is retained and  the  LLC2 connection out to a DSPU is replaced
by a DLS connection to a remote DLS router. It is the same idea as having token
ring and ethernet at either ends, except a channel connection is used in place of
either the ethernet or token ring.

The same is possible using a 3174 appearance to the mainframe. PU4 - my
specs out of date!

(**************************************************************************)

Subject: DLSw Matrix
From: "Shannon Nix" <[email-masked]>
Date: Thu, 6 May 93 09:12:49 EST

Could someone explain what is meant by enhanced SDLC support?  The issues I
have heard to date include: 1) secondary as well as primary  2) group poll
as either a primary or secondary station.  What, in the current DLSw
specification, is precluding an implementor from supporting primary,
secondary or negotiable link station roles as well group poll of any
flavor?  These seem like implementation choices rather than DLSw
issues.

The one possible implication, that I can see, would be in how the switches
handle the link station role negotiation in the XID3 exchange.  But we have
identified XID3 negotiation as a separate issue anyway.

Just curious,
Shannon

(**************************************************************************)

Subject: Re: DLSw Matrix
From: [email-masked]
Date: Thu, 06 May 93 08:58:21 PDT

Shannon-

>
>Could someone explain what is meant by enhanced SDLC support?  The issues I
>have heard to date include: 1) secondary as well as primary  2) group poll
>as either a primary or secondary station.  What, in the current DLSw
>specification, is precluding an implementor from supporting primary,
>secondary or negotiable link station roles as well group poll of any
>flavor?  These seem like implementation choices rather than DLSw
>issues.

    I believe you are right ... SDLC (and other DLCs, for that matter)
    are merely implementation choices at the ends.  For SDLC on both
    ends, I don't believe there are any SSP extensions required. But
    we need to make sure so we can accommodate the SDLC-to-SDLC market
    so consider "SDLC support" a placeholder until we look at it in
    more detail.

    Since cisco was the original requester of this feature, I'll do the
    detailed examination of SSP using cisco's STUN (serial tunneling)
    as a requirement and report to the group at our meeting in June.
    If we determine that SSP can do SDLC-to-SDLC, then we should drop
    that feature from the matrix.

(**************************************************************************)

Subject: SDLC Questions
From: [email-masked] (Paul Gacek)
Date: Thu, 6 May 93 09:15:55 PDT

>From: "Shannon Nix"
>Subject: DLSw Matrix
>Date:  5/06/93    Time:  9:12a
>
>Could someone explain what is meant by enhanced SDLC support?  The issues I
>have heard to date include: 1) secondary as well as primary  2) group poll
>as either a primary or secondary station.  What, in the current DLSw
>specification, is precluding an implementor from supporting primary,
>secondary or negotiable link station roles as well group poll of any
>flavor?  These seem like implementation choices rather than DLSw
>issues.

I agree group poll, primary and secondary support are implementation
 specific.

RFC 1434 is a little "light" on SDLC specific information. One area that
 is unclear to me is SDLC test processing. If we do something similar to
 the token ring processing of AREs as shown on page 12 of the RFC then
 an SDLC test frame generated by a host and sent to a host attached DLS
 router should result in a CANUREACH/ICANREACH/REACH ACK exchange
 with a CU attached DLS router.

This being the case I have a couple of questions:

1. How is test frame data transferred end to end? I seem to recall frames
 of the form F3 (Test), 12345...

2. After the CANUREACH/ICANREACH/REACH ACK exchange both
 DLS routers enter the CIRCUIT ESTABLISHED state. It is not clear how
 to process subsequent SDLC test frames.

(**************************************************************************)

From: Paul Gacek
Subject: Responses to enhancement querie
Date:  5/03/93    Time:  7:44a

>>>    b) SDLC up stream
>>This seems reasonable.  It is somewhat strange that this is not provided
>>considering that being a secondary SDLC station is substantially simpler to
>>implement than being a primary SDLC station.
>>
>I assume you are talking about the 6611 implementation which as you point
>out is a product detail. While I agree secondary SDLC is easier  than primary
>SDLC and therefore should "fall out" of any primary implementation, I
>believe the 6611 only supports primary SDLC at present. End to end SDLC
>is one way of supporting PU1 SDLC devices (the alternative involves LU 6.2).
>
>One SDLC end to end issue is handling of TESTs.
>
>>Since a router using DLS would presumeably deliver multiple logical link
>>connections to a single SDLC up stream (host) connection, it would seem to
>>me important that the up-stream connection support the group poll capability
>>already demonstrated on the 3174 token-ring gateway.  That would, in turn,
>>imply that the SDLC down-stream (terminal) support should be capable of
>>group polling an attached device.  That would require IBM releasing
>>additional documentation on how that protocol works.
>>
>Group poll - seems like a good idea but isn't this an implementation specific detail.

(**************************************************************************)

Subject: Flow Control and Test Command
From: [email-masked]
Date: Mon, 10 May 93 07:50:31 EDT
Message-Id: <[email-masked]>

SDLC test commands - Two signals exist for sending a test command from
one side to another over the WAN. They are TEST_REQ and TEST_RSP.
The TEST_REQ requests the receiving side to put a test command to the
device and the TEST_RSP is the response to that TEST_REQ. The TEST_REQ
does not have data associated with it. It is up to the side that
receives the TEST_REQ to add the data. The TEST_RSP also does not have
data nor any indicator to say if it was successful - data compare - or
not. It just says the test command was answered.
Note that this is special purpose and normal test_req and test_rsp never
get off the local DLS. If a device sends a test command to DLS, it is
returned by the local DLS and never goes over the WAN. The TEST_REQ and
TEST_RSP described are used by APPN for testing a circuit and measuring
the response time.

How about a naming convention for the two sides. Currently they are called
Blue and Gray. Any suggestions?
Dennis

(**************************************************************************)

Subject: IBM DLSw activity
From: "David Miller (254-5752)" <[email-masked]>
Date: Mon, 10 May 93 14:53:43 EDT

2.  NT 2.1

We are developing a mechanism for NT 2.1 that allows primary,
secondary, or negotiable attachment of a NT 2.1 device to the 6611.
This mechanism will allow SDLC-to-SDLC connectivity.  (We are
investigating this mechanism for use with other NT types including
NT 2.0 and NT 4)  In this mechanism, we map the SDLC flows to the
token ring flows as in the following scenario in which both
6611's are negotiable:

NT 2.1             6611                 6611                NT 2.1
XID3
-------------------->*                   *
XID3
-------------------->*                   *
                              .
    time passes               .
                              .
                      CURFRAME
                     *------------------>*
                                 ICRFRAME
                     *<------------------*
                      RESPACK
                     *------------------>*
XID3                   XIDFRAME           XID3
-------------------->*------------------>*------------------->*
                 XID3          XIDFRAME                  XID3 |
<--------------------*<------------------*<-------------------+
                              .
                              .
                              .
XID3                   XIDFRAME           XID3
-------------------->*------------------>*------------------->*
                 XID3          XIDFRAME                  XID3 |
<--------------------*<------------------*<-------------------+
SNRM                   CONTACT                           SNRM
-------------------->*------------------>*------------------->*
                  UA          CONTACTED                   UA  |
<--------------------*<------------------*<-------------------+
RR                                        RR
-------------------->*                   *------------------->*
                  RR |                                     RR |
<--------------------+                   *<-------------------+
                    I              IFRAME                    I
<--------------------*<------------------*<--------------------
|                RR                      |                 RR
+------------------->*                   +-------------------->

Note that all XID negotiation is performed at the EN for SDLC-to-SDLC
connections.

We have a prototype of this connection functioning correctly.

(**************************************************************************)

Subject: More SLDC Questions!
From: [email-masked] (PNGacek)
Date: Mon, 10 May 93 12:44:55 MDT

To: David Miller

In response your question asking which machines use TEST frames I seem to
recall System 3x
machines using TEST frames.

Maybe you can explain how SDLC end to end works in the area of link start
up. If a host is attached
via a leased line to a DLS router then normal start up consists of the
host SNRMing the configured
controllers (i.e no XID exchanges take place). Without any proceeding
SDLC activity what event has
established a circuit?  Do you rely on activity between the CU and the
(blue or gray?) DLS router to
establish the circuit  to the host attached DLS router?

Regards Paul Gacek
Novell

(**************************************************************************)

Subject: Various SDLC, Ethernet questions
From: "David Miller (254-5752)" <[email-masked]>
Date: Tue, 11 May 93 10:53:23 EDT

Paul,

SDLC Circuit establishment is initiated in two ways:
  1) POR - if the partner MAC address is defined, then the DLSw
     will attempt to activate the device (SNRM/UA) and if successful,
     will send a CURFRAME to the partner.  When an ICRFRAME is received
     from the partner, DLSw will return a RESPACK and mark the circuit
     as established.
  2) On receipt of a CURFRAME - if a CURFRAME is received for the
     MAC address of the SDLC station, DLSw will attempt to activate the
     device (SNRM/UA) and if successful, will send an
     ICRFRAME to the partner.  The circuit will be established once the
     partner returns a RESPACK.

(**************************************************************************)

Subject:  re:IBM DLSw activity
From: "Jim (J.) Cobban" <[email-masked]>
Date:  Tue, 11 May 1993 11:54:00 +0000

>There was a question awhile back regarding TEST frames and SDLC.  The 6611 MPQP adapter
>will reject a received TEST frame as a protocol violation.  Yes, use of the TEST
>frame is architected;  however, it is never used.  Most devices (if not all) do not
>send/receive TEST frames on SDLC lines.
>

If taken literally this statement is totally wrong.  In fact I am not aware
of a single IBM implementation of SDLC which does not send and receive TEST
frames (except, obviously, the 6611).  I must assume that the word
"unsolicited" was omitted by accident from the above statement.

Since the current 6611 only supports the attachment of secondary stations
then it is true that as long as the 6611 does not transmit a TEST frame, it
should never receive a TEST frame.  However all devices which can be attached
to a 6611 in this manner will correctly respond to a TEST frame if one is
sent to them.  It could be perceived as a product limitation that the 6611
does not provide this diagnostic test.  Since the 6611 is such a new product,
and since it is being sold into a market which has not been characterized by
the need to be able to manage large numbers of low-speed, low-quality lines it
is understandeable that it omits a considerable part of the traditional
diagnostic capabilities of SNA equipment.

The discussion of TEST frames arose specifically in connection with SDLC to
SDLC connections, and distinct from the requirement for support of T2.1.  It
is therefore clear that the support which is requested here is specifically
in relation to the 37xx NCP link level 2 test.

There are, it would appear, several aspects to the area of level 2 loop-back
testing.  The TEST frame is a somewhat inadequate tool because it does not
provide a mechanism for exp[licitly specifying the point at which loop-back
is to occur.  For an SDLC connection which traverses a router network it
would clearly be desireable to be able to:

   1) run a loop back test from the FEP port to the entry port to the router
      network.
   2) run a loop back test from the FEP port to the exit port from the router
      network.
   3) run a loop back test from the FEP port to the destination PU.

   +------+  SDLC  +------+  DLS   +------+  SDLC  +------+
   | 3745 |--------| 6611 |--------| 6611 |--------| 3174 |
   +------+        +------+        +------+        +------+
          <----1--->
	  <-------------2----------------->
	  <-------------------3-------------------->

The only obvious way to distinguish between these three tests is by using
different station addresses.  For management purposes it would also make
sense that the 6611 which is attached by an SDLC link to the host should also
have its own PU appearance.  Distinguishing between case 2 and case 3 is more
complicated because they are both carried over the same DLS connection, and
therefore would require two station addresses for each DLS connection.

Now that we have muddied the waters with TEST frames, how about LPDA?  If
there are diagnostic modems attached to the remote link, how could the
operator on the host run an end-to-end diagnostic test?

(**************************************************************************)

Subject: Re: IBM DLSw activity
From: [email-masked]
Date: Tue, 11 May 93 09:41:03 PDT

>>There was a question awhile back regarding TEST frames and SDLC.  The 6611 MP
>QP adapter
>>will reject a received TEST frame as a protocol violation.  Yes, use of the T
>EST
>>frame is architected;  however, it is never used.  Most devices (if not all)
>do not
>>send/receive TEST frames on SDLC lines.
>>
>
>If taken literally this statement is totally wrong.  In fact I am not aware
>of a single IBM implementation of SDLC which does not send and receive TEST
>frames (except, obviously, the 6611).  I must assume that the word
>"unsolicited" was omitted by accident from the above statement.
>
>Since the current 6611 only supports the attachment of secondary stations
>then it is true that as long as the 6611 does not transmit a TEST frame, it
>should never receive a TEST frame.  However all devices which can be attached
>to a 6611 in this manner will correctly respond to a TEST frame if one is
>sent to them.  It could be perceived as a product limitation that the 6611
>does not provide this diagnostic test.  Since the 6611 is such a new product,
>and since it is being sold into a market which has not been characterized by
>the need to be able to manage large numbers of low-speed, low-quality lines it
>is understandeable that it omits a considerable part of the traditional
>diagnostic capabilities of SNA equipment.
>
>The discussion of TEST frames arose specifically in connection with SDLC to
>SDLC connections, and distinct from the requirement for support of T2.1.  It
>is therefore clear that the support which is requested here is specifically
>in relation to the 37xx NCP link level 2 test.

[ *** remainder of Jim's response deleted *** ]

I agree with Jim's assessment.  SDLC TEST frames can't be ignored.

Cisco's SDLC-to-SDLC implementation in STUN (serial tunneling) treats
XID and TEST identically and handles each transparently when local
ack'd.  This means that they are merely passed through end-to-end in
all states without the routers trying to diddle with them.  Both TEST
and XID can happen at any time (e.g. non-negotiation XID3 exchange) and
only the SNA end systems care about their content.

As I indicated in an email last week, I will document cisco's basic
STUN functionality for the DLSw SIG effort.  It's been in the field now
for 2+ years and is used for PU4-to-PU2, PU4-to-PU4, and NT2.1-to-NT2.1.

Regards,
-----------
Wayne Clark
cisco Systems, Inc.
[email-masked]
415/688-4627

(**************************************************************************)

Subject: SDLC End-End
From: [email-masked] (PNGacek)
Date: Tue, 11 May 93 12:57:56 MDT

David

Thanks for the SDLC start up info.

What I think you  have described is two scenerios how a CU attached DLSw
activates  SDLC stations. These being 1) CU attached DLSw SNRMing a CU
based on locally configured info to do so and 2) CU attached DLSw SNRMing
a CU because it received a CURFRAME from a partner DLSw. The assumption
here is that the host attached DLSw is connected using Token-Ring to a
mainframe.

My original question relates to how station activation occurs (will
occur?)  in an SLDC end to end environment. Specifically in the area of
leased line attached DLSw (to hosts). Given that this scenerio does nor
include XIDs, how would  the circuit be established?

Returning to the start up info you supplied, I have the following
questions:

1) How is XIDing done at the CU attached DLSw in the following
configurations?
a) Direct connect or leased line attached CU
b) Dial up CU

Finally, which DLSw is gray and which one is blue?

Regards  Paul Gacek
Novell

(**************************************************************************)

Subject: Re: IBM DLSw activity
From: "Shannon Nix" <[email-masked]>
Date: Tue, 11 May 93 16:53:30 EST

SDLC TEST COMMANDS:

Traditionally the TEST command has been used by SDLC devices to diagnose
connectivity and its use is not restricted to circuit establishment.
While I agree with Wayne and Jim that SDLC TESTs shouldn't be ignored, I
think that they should be responded to locally by the boundary
DLSw.  It may not even be another SDLC connection at the other
boundary.

SDLC LINK STARTUP SEQUENCE:

As Paul pointed out, depending on the devices or configuration, there are a
variety of flows which may bring an SDLC link to a contacted state. For
each of those, there is more than one sensible way for an implementor to
map the interaction onto the state machine described in RFC 1434.
For instance, the implementation described by David describes a perfectly
reasonable way for a leased SDLC link activation to pass through a DLSw
cloud.

I cannnot think of an SDLC implementation which could not be
reasonably mapped onto RFC1434's state machine and, therfore, I
don't believe that RFC 1434 needs to be enhanced to support SDLC ( at least
not in the area of link establishment).

XID3 NEGOTIATION:

To the extent that this is possible, I think these should be allowed to
flow end-to-end.  There are, however, some fields which a DLSw is
required to or may want to "diddle" with:

 - ABM capable bit
 - Max frame size (MAXDATA)
 - Receive window size (MAXIN)
 - Link station role

I agree with Wayne that RFC 1434's state machine should allow an XIDFRAME
input in the CONNECTED state ( non-activation XID exchanges).

Q:  If neither end station is a NT 2.1, and, therefore, cannot negotiate
the max frame size, does the DLSw have to do segmentation and reassembly
(or segmentation minimally)?  Having written this down I've now convinced
myself that this is an implementor's choice as well.

LPDA:

Great question Jim!  How does the 6611 handle this?

Rgds, Shannon

(**************************************************************************)

Subject: DLSw Activity
From: [email-masked] (PNGacek)
Date: Wed, 12 May 93 13:43:57 MDT

Shanon

I have to disagree with your statement about documenting SDLC support in
the RFC. While I don't disagree that one can take the RFC as it stands
today and have a good stab at implementing a working product, I do
believe it is appropriate to include more information on SDLC, whether it
be on TEST processing, link activation or whatever. The RFC is very LLC
end - end centric. You and I may have the benefit of having worked on
conversion products before but others may not. If one of the goals of the
RFC is to provide information on how something works then it seems only
natural to include SDLC specific information.

Regards Paul Gacek
Novell

(**************************************************************************)

Subject: Re: DLSw Activity
From: "Shannon Nix" <[email-masked]>
Date: Thu, 13 May 93 12:17:03 EST

On Wed, 12 May 93 13:43:57 MDT, PNGacek wrote:

>Shanon
>
>I have to disagree with your statement about documenting SDLC support in
>the RFC. While I don't disagree that one can take the RFC as it stands
>today and have a good stab at implementing a working product, I do
>believe it is appropriate to include more information on SDLC, whether it
>be on TEST processing, link activation or whatever. The RFC is very LLC
>end - end centric. You and I may have the benefit of having worked on
>conversion products before but others may not. If one of the goals of the
>RFC is to provide information on how something works then it seems only
>natural to include SDLC specific information.
>
>Regards Paul Gacek
>Novell

Paul,

I will try qualify my statements regarding SDLC support.  My perception of
the scope of the work undertaken by this SIG is to specify
what is necessary to produce interoperable DLSw implementations.  I had,
therefore, interpreted that effort as concisely describing the interactions
between DLSw implementations.  IBM have provided a good foundation for that
work with the Switch-to-Switch Protocol (SSP) described in RFC1434.

To date, I have seen no compelling argument which would imply that SSP
should get "thicker" to support SDLC ( one possible exception being
enhanced diagnostic capabilities - ala LPDA).  I certainly appreciate the
issues that face an DLSw implementor choosing to terminate SDLC links of
any flavor.  They are many of the same issues that Netlink and other
vendors have been solving in the field for the last two years. I simply
view them as boundary issues for a DLSw implementor rather than
interoperability issues.

If this group desires a broader scope for their work, that is, describing
all aspects of DLSw function rather than simply how DLSw implementations
interoperate, then add Netlink to the SDLC interest matrix as an very
interested party. There are certainly a number of SDLC termination issues.
My point is, that vendors may have varied solutions to these issues and
still interoperate by conforming to an RFC1434-like spec.

What are this group's feeling as to the scope of this effort?  Perhaps, as
Wayne originally suggested, drafting a charter would help clarify this
scope?

Rgds, Shannon

(**************************************************************************)

Subject: Various SDLC
From: "David Miller (254-5752)" <[email-masked]>
Date: Thu, 13 May 93 15:58:12 EDT
Message-Id: <[email-masked]>

1)  SDLC end-to-end

For SDLC end to end, the following scenario could be used:

3745               6611                 6611                PU 2.0
                              .
                              .
                              .
                        topology xchg
                     *<----------------->*
                              .
                              .
                              .
                      CURFRAME
                     *------------------>*
                                 ICRFRAME
                     *<------------------*
                      RESPACK
                     *------------------>*
                              .
                              .
                              .
SNRM                   CONTACT                           SNRM
-------------------->*------------------>*------------------->*
                  UA |                                    UA  |
<--------------------+        CONTACTED  *<-------------------+
                     *<------------------*
RR                                        RR
-------------------->*                   *------------------->*
                  RR |                                     RR |
<--------------------+                   *<-------------------+
                    I              IFRAME                    I
<--------------------*<------------------*<--------------------
|                RR                      |                 RR
+------------------->*                   +-------------------->

The new flow "topology xchg" (TX) is not currently in RFC 1434, nor
is it implemented by IBM.  However, we think it is a good idea to
cut down the number of excessive broadcasts and to limit customer
configuration.  Without it, both 6611s would have to define MAC
addresses for their respective SDLC stations.  One side at a minimum
would have to know the MAC address of the other.  This side would
simulate the receipt of a TESTFRAME and send out the CURFRAME.
With TX, the routers, during initial bringup, could
exchange topology information detailing permanent resources
(such as SDLC stations) or non-permanent resources (such as LAN
devices.)  This has several advantages:
  1.  With the current scheme, MAC addresses would have to be
      defined for both the 3745 and the PU2.0.  With a flat MAC
      address space, management of all these addresses can be
      horrendous.
  2.  SDLC devices could now be locally defined by something other
      than MAC addresses, allowing the use of link/address pairs
      or names to uniquely identify SDLC stations.
  3.  Use of topology information to preload any routing cache increases
      its hit rate.  The higher the hit rate for the
      routing cache, the lower the numbers of broadcast CURFRAMEs and
      higher the numbers of directed CURFRAMEs.

(**************************************************************************)

Subject:  Mapping messages to DLS Circuits
From: "Jim (J.) Cobban" <[email-masked]>
Date:  Mon, 17 May 1993 14:48:00 +0000

I am unclear on some of the details of how the finite state machine is driven
during circuit establishment.

The finite state machine which is defined in RFC1434 is associated with a
specific circuit, as discussed in section 4.2.  But not all messages
exchanged between data link switches, or between data link switches and their
associated data link control interfaces carry a circuit identification.  For
example the CANUREACH message is shown in the figure on page 9 as carrying
only a data link ID.  This is certainly reasonable, since the sending switch
cannot know what circuit ID to place in the packet, that being assigned by
the receiver.  The receiver must make a decision as to which FSM to send
the message to based upon the data link ID.  I assume that the receiver

 1) creates a brand new FSM to process the CANUREACH message,
 2) performs the local contact process.  If that process fails, delete the
    FSM
 3) if the local contact process succeeds change state to CIRCUIT_PENDING
    (not shown on page 9) send the ICANREACH with the half-circuit ID
    of the created FSM.

For no obvious reason the sending DLS has overridden the DSAP provided by the
originating station to match the OSAP.  Why is that value for DSAP any more
appropriate than any other?  In order to behave like other SNA devices on the
destination ring, the switch should send the local TEST frame out with a DSAP
of 0 anyway.

The circuit establishment process as it is described in RFC1434, for a
typical SNA TRN implementation which sends a TEST with DSAP 0 and OSAP 4
would result in the creation of a circuit for DSAP 4 and OSAP 4.  If the
originating station then sends a SABME with that pair of SAPs everything is
fine because that results in a DLC_CONTACT input to a FSM in state
CIRCUIT_ESTABLISHED.  But what happens if the station decides that it wants a
second SNA connection, but decides to use its existing knowledge of the
source-route to the destination MAC, discovered by the TEST?  The station
then sends a SABME with OSAP 4 and DSAP 8?  This requires a new circuit but
we have not negotiated the circuit IDs.  There is no FSM to deliver this
message to!  Note that there is no change to my concern if the station
chooses to send an XID before the SNRM.

I know that these comments are somewhat incoherent, but I am having
difficulty in determining. with precision, exactly how messages are mapped to
circuits.  The document does not make this clear.  The document also does not
say what header fields are valid for various requests, nor what values are
inserted into header fields which are unknown to the sender.

RFC1434 as it stands is not the place to discuss the various DLC
implementations.  However it seems that there must be some document, or
appendix which discusses how some specific implementations of DLC map to the
DLC events which are inputs to the DLS FSM, and how DLC actions are mapped to
DLC frames.  One value of such an exploration is that you can ensure that
there is a valid mapping.  I am not certain, at present, that a DLC function
can map frames to DLC events without knowledge of the internal state of the
DLS circuit that the events are to be delivered to.

(**************************************************************************)

Subject: Flow Control & Link Act
From: [email-masked] (PNGacek)
Date: Mon, 17 May 93 13:08:26 MDT
Message-Id: <[email-masked]>
Cc: [email-masked], [email-masked]

David

Link Activation

Currently, the RFC defines sending an RNR after a SABME/UA sequence. I
assume this is done to avoid timeout problems. A small window exists
between the UA and RNR that the other end could send I frames (typically
1). With SDLC end to end this seems a bit more of a problem as the
secondary can't send an RNR until it gets permission, usually in the
first I frame (containing an ACTPU Rq) or soon after.

While I readily admit these are implementation details, tieing the UA to
the CONTACTED message would avoid frame  buffering (potentially at the
expense of timeout problems).

Any thoughts?

Paul Gacek
Novell

(**************************************************************************)

Date: Wed, 2 Jun 93 16:12:45 EDT
From: "David Miller (254-5752)" <[email-masked]>
To: [email-masked]
Subject: cap exch
Status: R

> =========+====+
> cap exch |    | Sounds good in principle, but wouldn't that be covered by
> =========+====+    XID3 (-> NT 2.1) ?

The capabilities exchange discussed in this matrix is different than that
in the NT2.1 XID exchange.  This is a cap exch between the routers as
opposed to a cap exch between the end devices.  There exists a need for
the routers on opposite ends of the circuit to establish common grounds
for routing traffic to one another, such as window sizes for pacing
and other pacing capabilities.  The XID flow establishes the
capabilities of the end stations, which do not need to know that the
actual circuit is being terminated by the router.

David Miller

(**************************************************************************)

Date: Fri, 11 Jun 93 17:28:05 EDT
From: [email-masked] (Himanshu C. Shah)
Message-Id: <[email-masked]>
To: [email-masked]
Subject: DLSw RFC related questions
Status: R

Hi, 

I am coming upto speed on DLS and a new member of SIG. I am not very familiar
with SNA or NetBios but just with the bridging and may be this is a blessing
in disguise. I think the goal for DLS should not be limited to overcome
the shortcomings of SNA or NetBios but any other protocols that use 
connection oriented data link layer in a remote bridge environment. May be
this is a non-goal, if so, let me know.

I have several questions, some of which may have been discussed in the past
and is probably re-asked here with a different twist.

1) I plead ignorance here since I have not put DLS state machine under
microscope, But my general question is, Is DLS state machine capable of
handling switching following data link matrix, first as a single DLS entity
and secondly as a DLS pair over TCP. If not, we should make necessary
adjustments.

	SDLC(p)  <==> SDLC(s)
	SDLC     <==> LLC2
	LLC2     <==> LLC2

2) What does +really+ uniquely identify a single end-to-end connection 
between two end stations? 
	1) Pair of circuit IDs + Pair of Transport Ids
 or	2) Pair of circuit IDs + data link ID
 or	3) Pair of circuit IDs + Pair of Transport Ids + data link ID

I am wearing a network manager cap here who is really collecting all the
topology tables from the DLSs and want to identify/manipulate a one
entire link.
BTW, does there exist an "identifier" for a DLS which uniquely identifies
a DLS and is an IP address a part of the identifier. 

It is nice to exchange two levels of data link cookies (circuit ID) and 
transport id (a TCP session handle), but these have local significance
and not unique across the network. Only thing unique is data link ID which
I am afraid with locally-administered addresses and well known SAP usage
may not be unique (and only RIF can be a tie-breaker, oh god no!!).

3) What kind of information is cached from C-U-R message? (MACaddr, IPaddr,
transport ID, SAP(?))

How long is this information kept?

Is cache aged? (what age, what resolution), refreshed? (from what?)

4) Why is I-C-R message not considered as a candidate for broadcast?
Given the nature of client-server model in SNA, caching of information
from ICR has greater significance and will cut down a large number of 
broadcast directed CURs. 

Why is the state machine so primitive that in disconnected state if it
receives an unsolicited ICR it steps into circuit-established state?

5) Why is there no end-to-end MTU negotiation? We need  a field in
the control header which represent MTU. As we know, target DLS may try to
find the destination in a source route bridged environment where LF-bit
negotiation is important criteria for the path selection. Last thing one
wants, is to have TCP circuit established but target DLS drop the I-frames
because they are too big to go through SRBs.

6) Page 8, 2nd paragraph describes what target DLS does when CUR is received.
I think there is a whole lot of information that is missing here.

	a) How is TEST frame sent? Is it source routed? STE? ARE? To what
	SAP? (0x00, 0x04).

	b) If ARE what is the criteria for selecting the best path? First
	arrived with suitable MTU? (See (5) for lack of information on 
	what a suitable MTU is)

	c) How long does Target DLS wait before giving up on TEST response
	and get rid of the control structure?

	d) How long does source DLS wait before giving up on ICR and free
	up the resources?

7) What does source DLS do when it has multiple CUR candidates to the 
same destination MAC address and it is pending on ICR?

8) What about transparent bridging support? As we know there is no standard
for Source Route Bridging. There is a draft standard IEEE802.5M/D7 for SRT
which is now close to become a standard and will be added as an 
addendum to IEEE802.1d standard. According to this standard, a token ring
port in a bridge will support both Source route bridge as well as 
transparent bridging. If an end station uses A & C bit setting on a
transparent test frame to decide whether the destination is locally present
on the ring or not, this will present a problem for Data link Switches in SRT 
bridged LAN. In order to prevent loop through the DLS cloud, Spanning Tree
Protocol becomes a necessity. 

We must have a code point in the control header to pass Hello BPDUs around
to form a spanning tree and break the loops.

There is also another standard evolving for end stations, called 
Route Determination Entity (RDE), to select a suitable frame format in 
different bridged environment. RDE defaults to transparent bridged 
environment.

9) Page 9, 2nd paragraph, suggests NetBios control message include RIF
in the DLC header which should be padded to 18 bytes, WOW!!

Why is DLS responsible for this? Why should it be,

	a) source routing frame
and	b) a rif with 18 bytes (standard allows upto 30 byte RIF)
and	c) padded (there is no such standard where padding is required)
and	d) with all these additional work, destination DLS throws the RIF
	away anyway...

10) section 4.1.2: Link Restart Protocol. Why is 'link restart' treated as
disconnect on the data link side when there does exist a 'link reset' concept?

Is this SNA or NetBios specific characteristics? Is this good enough
reason for a general-purpose DLS goal?

Editorial: paragraph 4 in the same section. 'CONNECT' probably means 
'CONTACT'.

Stay tuned, I have more..

Himanshu

(**************************************************************************)

From: [email-masked] (Himanshu C. Shah)
Message-Id: <[email-masked]>
To: [email-masked]
Subject: More DLSw RFC related questions/issuess
Status: R

Hi,

Some more questions/issues while reading through DLSw RFC.

1) Page 12, section 4.2, bottom of second paragraph. This paragraph
suggests that as per SAP values, the test frames are submitted to DLS
and one would either bridge or switch the SNA frames.

I contest this to be not true. The DLS box would simultaneously bridge
the test frame and send CUR on the DLS cloud. Based on the various
responses, in case if there are more than one, the end station bears
the responsibility of route selection. Therefore, DLS should appear
to end stations as just another path to the destination, in cases
where there is a bridge path as well as a DLS path. Basically, it
boils down to the question, whether data link switching should be
transparent to the end station or not?

2) Table 3 on page 15 in section 4.2.2. This table should include the
events "DLC_ENTER_BUSY" to handle receipt of an RNR from the end
station and "DLC_EXIT_BUSY" to handle receipt of an RR from the end
station. I am assuming that DLS spec will evolve to provide flow
control on per cicuit basis.

3) I remember seeing discussion in mail archives about the setting of DSAP
to SSAP for CUR. My opinion is that DSAP should be hard coded to SAP
0x04 for SNA frames for a legible data link ID.

Himanshu.

(**************************************************************************)

Date: Wed, 16 Jun 93 09:30:23 EDT
From: [email-masked] (Himanshu C. Shah)
Message-Id: <[email-masked]>
To: [email-masked]
In-Reply-To: alan bartky's message of Tue, 15 Jun 93 16:33:40 PDT <[email-masked]>
Subject: More DLSw RFC related questions/issuess
Status: R

>In Mr. Himanshu's C. Shah's comment that the DSAP should be hard coded to
>0x04 for SNA frames, we at Sync Research disagree.

>SNA (in IBM manuals) defines using 4, 8, or 0x0c in many of the IBM manuals.
>Sync Research's and Netlink's current SDLC to LLC converters use those SAPs
>and others.  This is required as most 3725s, 45s and 3174 Gateways use SAP
>4 and only 4, and a converter must be able to use SAPs other than 4 in order
>to establish multiple LLC connections between the converter and the remote
>SNA device as each PU requires it's own LLC connection.  Since the remote
>SNA device typically has 1 MAC address and 1 SAP (SAP 4), the converter only
>has one MAC address, so the only way to establish more than one LLC connection
>is to use SAP values other that 4.

Given the nature of SNA where clients are initiating the connections
to server (via test/xid frames), one can form multiple LLC connections
by having DSAP hard-coded to 0x04 and SSAP to any other value, which I
believe you use to denote an SDLC device/port.

By having DSAP set to SSAP in CUR data link ID, you are stuck with
data link ID that represents nothing. For example, if SSAP used is
0x12 (some user configured value), the data link ID formed as per RFC is
DA-SA-0x12-0x12. Neither server nor client produce any LLC frame that
matches this DSAP/SSAP combination. If hard-coded, data link-Id would
look like DA-SA-0x04-0x12.

This is my understanding. Please correct me if I am wrong.

Himanshu.

(**************************************************************************)

Date: Wed, 16 Jun 93 07:40:03 PDT
From: [email-masked]
Status: R

David -

    In early May, I had volunteered to discuss SDLC-to-SDLC tunneling from 
    the perspective of cisco's STUN and DLSw.  That doesn't show up 
    anywhere in your list below.  I've included the corroborating email 
    at the end of this message.

    Also, I don't agree that the charter discussion should be last.  It
    is too important to "fall off the agenda".  It should be first with a
    time limit placed upon it.  Without a charter, this standardization
    effort is a farce.

Wayne Clark
cisco

(**************************************************************************)

Date: Wed, 16 Jun 93 13:45:29 EDT
From: [email-masked] (Himanshu C. Shah)
Message-Id: <[email-masked]>
To: [email-masked]
Cc: [email-masked]
In-Reply-To: alan bartky's message of Tue, 15 Jun 93 16:33:40 PDT
Status: R

Subject: More DLSw RFC related questions/issuess

>In Mr. Himanshu's C. Shah's comment that the DSAP should be hard coded to
>0x04 for SNA frames, we at Sync Research disagree.

>SNA (in IBM manuals) defines using 4, 8, or 0x0c in many of the IBM manuals.
>Sync Research's and Netlink's current SDLC to LLC converters use those SAPs
>and others.  This is required as most 3725s, 45s and 3174 Gateways use SAP
>4 and only 4, and a converter must be able to use SAPs other than 4 in order
>to establish multiple LLC connections between the converter and the remote
>SNA device as each PU requires it's own LLC connection.  Since the remote
>SNA device typically has 1 MAC address and 1 SAP (SAP 4), the converter only
>has one MAC address, so the only way to establish more than one LLC connection
>is to use SAP values other that 4.

Given the nature of SNA where clients are initiating the connections
to server (via test/xid frames), one can form multiple LLC connections
by having DSAP hard-coded to 0x04 and SSAP to any other value, which I
believe you use to denote an SDLC device/port.

By having DSAP set to SSAP in CUR data link ID, you are stuck with
data link ID that represents nothing. For example, if SSAP used is
0x12 (some user configured value), the data link ID formed as per RFC is
DA-SA-0x12-0x12. Neither server nor client produce any LLC frame that
matches this DSAP/SSAP combination. If hard-coded, data link-Id would
look like DA-SA-0x04-0x12.

This is my understanding. Please correct me if I am wrong.

Himanshu.

(**************************************************************************)

From: "Bernard Brady" <[email-masked]>
Subject: Re: More DLSw RFC related questions/issuess
To: [email-masked]
In-Reply-To: <[email-masked]>
Date: Wed, 16 Jun 93 14:54:56 EDT
Mail-System-Version: <BBN/[email-masked]>
Status: R

Hi,

A question/issue while reading through DLSw RFC.

Does anyone know why  both the Message Length and Message Type
fields are defined twice in the control message header?  The RFC notes
that they are specified two places within the header but gives no reason.

Bernie Brady

[email-masked]

(**************************************************************************)

Date: Wed, 16 Jun 93 15:34:42 EDT
From: [email-masked] (Himanshu C. Shah)
Message-Id: <[email-masked]>

My guess would be that Information Message header is slapped on to the
control message header (may be at a later stage as a part of a bug
fix??).  May be that is why there is also an overlap of data link
correlator+dlc port id (remote, origin and target, why three??).

Himanshu.

(**************************************************************************)

Date: Wed, 16 Jun 93 15:44:30 EDT
From: "David Miller (254-5752)" <[email-masked]>
To: [email-masked]
Subject: More DLSw RFC related questions/issuess
Status: R

> My guess would be that Information Message header is slapped on to the
> control message header (may be at a later stage as a part of a bug
> fix??).  May be that is why there is also an overlap of data link
> correlator+dlc port id (remote, origin and target, why three??).
>
> Himanshu.

Very close guess Himanshu.  The Info Msg header was added at a later
stage not to fix a bug but for performance reasons.  Most of the
fields within the header are only needed during circuit establishment.
Once the circuit is established fewer fields need to be transferred.
This means less bandwidth on the network is dedicated to overhead
when passing lots of data packets.

David Miller

(**************************************************************************)

From: alan bartky <[email-masked]>
Subject: Comments on CANUREACH DSAP field for SNA
Date: Wed, 16 Jun 93 12:55:43 PDT

After Reading Jim Cobban's (BNR), Himanshu Shah's (Proteon) comments and
then reading RFC1434 again I have concluded the following.

1) Jim is correct in that the TEST frame sent out on the destination ring
should send out the TEST frame with a DSAP of 0.

2) Jim is also correct in that if the CANUREACH message sets the DSAP=SSAP,
it will cause the circuit IDs to only work if the DSAP=SSAP (as shown
in the diagram of RFC1434 page 10 in section 4.1.1).

This would cause DLSw to only work for LLC connections that have DSAP=SSAP.
All SDLC to LLC converter products must use multiple SAPs in order to
establish multiple LLC2 connections on behalf of the downstream SDLC PUs.

If the DSAP=SSAP method is currently being used by the 6611, then 
the 6611 would not work properly with SDLC to LLC converters that are
connected on downstream LANs from the 6611!

3) Himanshu's suggestion that the DSAP in the CANUREACH message be hard
coded to 4 would work in most cases but not all.  If an SNA Host were to 
contact a downstream SNA device (SNA outdial on token ring) it's DSAP
would be 4 and the downstream LLC Device may not necessarily be 4.  Again
if it were a converter or other downstream device that used a SAP value other
than 4, the value would not work.  It also would not work for upstream
connections where the SAP was not 4 (either another converter or an SNA
host were configured for a SAP of 8 or 0x0C, look it up in your IBM manuals,
it's allowed).

4) The diagram under 4.1.1. does not show the XID exchange sequence.  I
don't know of any SNA connect sequence that does not use XIDs.  It should
be in the diagram (it does mention later that XID frames may be exchanged
once the circuit is established).

5) Some SNA devices use an XID rather than a TEST frame to establish a
source route path (including some IBM products).  These devices must
be supported also.

6)  It seems to me that the real function of a CANUREACH should be only
to determine if a given MAC address can be reached and that it should not
be used to set the circuit ID.  The circuit ID would be best to be set
when the first XID (or TEST) frame was sent with a DSAP that is not equal
to 0.  This would eliminate the problem of trying to arbitrarily set the
DSAP=SSAP which is not always a valid assumtion.  In SNA the first XID
after the TEST message contains a valid DSAP and SSAP rather than using
a SAP of 0.  I am not as knowledgeable about NETBIOS, but if it uses a 
TEST or an XID with a DSAP of F0, then that would be the appropriate time
to set the circuit ID.

As far as item 6 goes, I am still of the opinion that we should try to
come to a quick conclusion as far as agreeing on the RFC.  I will not
however agree to any standard that causes SDLC to LLC conversion to not
interoperate with DLSw.  It may be necessary to use Himanshu's sugestion
of hard coding the DSAP to 4 in order to proceed (at least it would work
for most cases).

After understanding this issue more, I would definetly want to discuss it
next week in Raleigh during the technical discussions.

Regards,
Alan K. Bartky ([email-masked]) 714-588-2070
Sync Research Inc.

(**************************************************************************)

Date: Wed, 16 Jun 93 16:01:49 EDT
From: [email-masked] (Himanshu C. Shah)
Message-Id: <[email-masked]>
To: [email-masked]
Subject: RFC DLSw
Status: R

Since there is a lot of meeting agenda related concerns being
exchanged, since I am not attending the meeting, I am submitting the
following list that I had like discussed and the result posted after
the meeting.

The following issues are hinderance to interoperability from my
perspective, hence I had like them to be rectified or clarified.

1) I had like a field in the Control Message Header to place an MTU
value.

2) I had like a field in the Control Message Header to place the
segment number of the DLS cloud, so I can idiot-proof the user
configuration of the DLS segment. I had also like an "error" type of
message/mechanism to kick out a wrongly configured DLS.

3) I had like to have state machine rectified such that
unsolicited ICANREACH message does not cause the receiving DLS to
become confused and/or step into circuit established state.

4)I had like proper "data link ID" issue ironed out so that everybody
is in-sync with what the DSAP should be for CANUREACH message.

5) I had like some guidelines specified on default timeout for source
DLS pending on ICANREACH and target DLS pending on TEST response. This
has interoperability issue as source DLS should not give up before
target DLS on TEST response plus the max.round trip delay in the
cloud.

Himanshu
 
(**************************************************************************)

From: "Bernard Brady" <[email-masked]>
Subject: Re: More DLSw RFC related questions/issuess
Date: Wed, 16 Jun 93 16:20:34 EDT
Status: R

>Received: from ibmstandards.cary.ibm.com by BBN.COM id aa17059;
David,

Your comment explains the  reason for the separate Info Msg but not why
there are duplicate fields defined in the control header.  Since the
data is going over a reliable transport it doesn't seem to be needed. 
Are there any plans on removing the redundancy?

Bernie

>Date: Wed, 16 Jun 93 15:44:30 EDT
>From: "David Miller (254-5752)" <[email-masked]>
>To: [email-masked]
>Subject: More DLSw RFC related questions/issues
>
>> My guess would be that Information Message header is slapped on to the
>> control message header (may be at a later stage as a part of a bug
>> fix??).  May be that is why there is also an overlap of data link
>> correlator+dlc port id (remote, origin and target, why three??).
>>
>> Himanshu.
>
>Very close guess Himanshu.  The Info Msg header was added at a later
>stage not to fix a bug but for performance reasons.  Most of the
>fields within the header are only needed during circuit establishment.
>Once the circuit is established fewer fields need to be transferred.
>This means less bandwidth on the network is dedicated to overhead
>when passing lots of data packets.
>
>David Miller

(**************************************************************************)

Date: Thu, 17 Jun 93 18:08:59 EDT
From: "T. M. Danninger ((919)-254-6328)" <[email-masked]>
To: [email-masked]
Subject: Wayne Clark's Offer to Present STUN
Status: R

Wayne,

Just speaking for myself I'd be very interested in seeing the STUN
SDLC to SDLC approach that CISCO has.  However, I, personally, am
unwilling to use SIG time to see it.  It is not on the matrix and my
preference would be that we find another forum to explore it as it
appears that we're going to be very pressed to address the key items
on the matrix.

Regards,

Tom Danninger

(**************************************************************************)

Date: Thu, 17 Jun 93 19:42:13 PDT
From: [email-masked]
Status: R

>Wayne,
>
>Just speaking for myself I'd be very interested in seeing the STUN
>SDLC to SDLC approach that CISCO has.  However, I, personally, am
>unwilling to use SIG time to see it.  It is not on the matrix and my
>preference would be that we find another forum to explore it as it
>appears that we're going to be very pressed to address the key items
>on the matrix.
>
>Regards,
>
>Tom Danninger

Tom -

    There are two things that I wanted to demonstrate to the SIG early
    in the process before the working group got too far down the path
    with DLSw as it is today:
	(1) SSP is designed specifically for a DLC protocol that has a
	    discovery mechanism (i.e. LLC2), and
	(2) by DLSw providing complete DLC termination of everything
	    (including in the Disconnected state), you're making life
	    very difficult for yourselves.

    To state it bluntly, number (1) means that SDLC-to-SDLC cannot be
    accommodated in DLSw as it stands today.  Number (2) means that
    NT 2.1 support will be a whole lot more complicated with DLSw than
    it needs to be.
    
    After seeing SSP, it became real obvious why the 6611 only
    supported LLC2-to-LLC2 and LLC2(host)-to-SDLC(remote).  I do
    believe SSP can be extended to handle non-LLC2 connections (i.e.
    SDLC, QLLC, channel, etc.) but it is definitely not there today.

    Given the proposed agenda:
	  - 5 45 (+/-) minutes sessions

	  - Session 1:  Flow Control
	  - Session 2:  NT 2.1 Support
	  - Session 3:  Capabilities Exchange
	  - Session 4:  General discussion of technical matters not
	      discussed in previous sessions
	  - Session 5:  Charter discussion

    Session 2 is unnecessary if the SIG listens to the alternative approach
    that I'm alluding to above.  NT 2.1 support (i.e. XID3 negotiation)
    comes for free if you allow TEST and XID passthrough.  Simple, but
    elegant ... and it works.

    What do other members feel?  Vote fast!

Wayne

P.S. Tom, it is on the matrix ... that's what the entry "SDLC" was supposed
     to mean.  Robin Layland is right - we've got to explain what these
     bullet items stand for.

(**************************************************************************)

Date: Fri, 25 Jun 93 12:59:00 EST
From: Larry Samberg <[email-masked]>
Message-Id: <[email-masked]>
To: [email-masked]
Subject: Some general concerns/issues
Status: R

Now that I have had a few days to immerse myself in DLSw related issues,
I have a number general concerns/questions. I would appreciate any answers,
information, concurrence, or indication that any of these aren't really
problems:

1. Support for duplicate TIC addresses in 3745s - Our first release
of PIR chose one TIC and just used it until it died and then switched to the
other. We were beat up by our customers who wanted to preserve the
load-balancing effects of dual TICs. My perception is that unless the
two TICs are reachable through the same DLS switch, DLS suffers the same
problem. Yes?  (note: PIR is CrossComm's technique for routing SNA).

2. Are the MAC addresses stored in SSP message canonical or in Token
Ring format? Have the tranlational bridging issues been addressed?

3. The spec doesn't discuss configuration very much. I infer that the
virtual ring alluded to must be unique on each switch. Am I correct?

4. As was pointed out in some other mail (Mr. Shu I believe) not propagating
the RIF/LF bits back to the source can result in a partitioning of the
network.

5. The lack of dynamic discovery scares me. I can't imagine a customer
configuring 60 (or even 30) switches correctly (and independently).

6. I haven't worked this out, but are there any possibilities of unnecessary
looping of SRB/ARB frames (or more politically correct STE/ARE frames) if
there are two DLS paths in parallel or a DLS path and an SR Bridge path?
How does DLS interact with the spanning tree setup for STE frames?

- Larry Samberg

(**************************************************************************)

Date: Fri, 25 Jun 93 14:11:41 EDT
From: [email-masked] (Himanshu C. Shah)
Message-Id: <[email-masked]>
To: [email-masked]
Cc: [email-masked]
In-Reply-To: Larry Samberg's message of Fri, 25 Jun 93 12:59:00 EST <[email-masked]>
Subject: Some general concerns/issues
Status: R

Although I am not a SIG 'electorate', I love to indulge into technical
discussion. Forwarned, I am still a grasshopper.

1. Support for duplicate TIC addresses in 3745s - Our first release
of PIR chose one TIC and just used it until it died and then switched to the
other. We were beat up by our customers who wanted to preserve the
load-balancing effects of dual TICs. My perception is that unless the
two TICs are reachable through the same DLS switch, DLS suffers the same
problem. Yes?  (note: PIR is CrossComm's technique for routing SNA).
------
1) Duplicate MAC addresses in TKR environment risiding on differnet
rings (Of course, IEEE802.5 MAC will not even allow you to join the
ring with dupplicate address) can happen only in Source Routing Bridge (SRB)
environment. In transparent bridge environment, traffic will fluctuate
from one ring to other ring as bridge keeps learning from differnt
interfaces. 

In the SRB environment, source station selects the route. For example,
if DLS is initiating the connection on DLC_START_DL command, DLS is
responsible to select a route to destination which could be upto 14
hops away. Once, you select the route, all LLC2 frames will use the
same RIF (including the ones DLS doesn't know about, e.g. RR frames).

Unless you device your own mechanism to detect a failed route and
start using the alternate route or do reexploring without breaking the
data link connection, there is no information/guidelines in RFC.

Hence, even if the same DLS is reachable to two TICs, the problem
exist. If two TICs are directly connected to DLS, they are visible via
different interfaces and hence you still need some mechanism to detect
the unreachability and switch over.
-----------

2. Are the MAC addresses stored in SSP message canonical or in Token
Ring format? Have the tranlational bridging issues been addressed?

	Current RFC assumes token ring and source routing environment. Hence I
will assume the address in non-canonical (token ring format) format.

-----------

3) 3. The spec doesn't discuss configuration very much. I infer that the
virtual ring alluded to must be unique on each switch. Am I correct?

No. As a matter of fact the virtual ring denoted to DLS cloud MUST
be unique in all the DLSs. If not, you may risk looping and/or traffic
reentering the DLS cloud by parallel DLS. 

I believe that RFC should accomodate a mechanism to ensure the virtual
ring number integrity amongst the participating DLSs.

------------

4) 4. As was pointed out in some other mail (Mr. Shu I believe) not propagating
the RIF/LF bits back to the source can result in a partitioning of the
network.

That is Himanshu and not Mr. Shu..(ask Nick Grewal for
pronounciation..)

I agree.

----------

5)5. The lack of dynamic discovery scares me. I can't imagine a customer
configuring 60 (or even 30) switches correctly (and independently).

Multicast OSPF??

Also, if you have client-server network, only at server site DLS, you
have to configure all the client IP addresses. At all client site DLS,
all you need to configure is server side DLS IP address only.
------
6)6. I haven't worked this out, but are there any possibilities of unnecessary
looping of SRB/ARB frames (or more politically correct STE/ARE frames) if
there are two DLS paths in parallel or a DLS path and an SR Bridge path?
How does DLS interact with the spanning tree setup for STE frames?

Not really. Work it out with (3) in mind and the fact that SRBs sheds
frames with Duplicate LOUTs in the frame.

Himanshu.

(**************************************************************************)

Date: Fri, 25 Jun 1993 11:28:55 -0700
From: Choon Lee <[email-masked]>
Message-Id: <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re:  Some general concerns/issues
Status: R

>> 3. The spec doesn't discuss configuration very much. I infer that the
>> virtual ring alluded to must be unique on each switch. Am I correct?
>> 
I believe that all switches use a common virtual ring number. This way the
loops cannot form (e.g. frames cannot get back into the "DLS cloud" again
if it has been in there once)

>> 6. I haven't worked this out, but are there any possibilities of unnecessary
>> looping of SRB/ARB frames (or more politically correct STE/ARE frames) if
>> there are two DLS paths in parallel or a DLS path and an SR Bridge path?
>> How does DLS interact with the spanning tree setup for STE frames?
>> 
For SR frames, loop formation is avoided by the common virtual ring.
A sub-workgroup (aiw-sig-dlsw-loopprevention) has been formed to work on the 
loop prevention problem in the non source-routing case.

>> - Larry Samberg

/choon lee

(**************************************************************************)

Date: Fri, 25 Jun 93 14:54:22 EDT
From: [email-masked] (Scott Barvick)
Message-Id: <[email-masked]>
To: [email-masked]
Subject: RE: general concerns cont.
Status: R

I agree with Larry's issues and most of Himanshu's responses
except for the configuration aspects and the looping ring numbers.

1) Configuration:  DLS does not require both partners to be configured
for each other.  In the client server network, if all of the clients
are configured with the single server DLS IP address and the server DLS is
able to accept connections from unconfigured peers, then the server DLS can
wait for TCP connections from the client switches.  

Nonetheless, some type of discovery would be very useful.

2) Looping SR explorers.  While configuring all DLS switches with
the same virtual ring number eliminates looping through the DLS
backbone, a backup SR bridge connection which connects regions also
connected by DLS switches will result in looping of the explorers once
more within the source routed LAN portion of the network.  Painful
experience has shown this to hang some end stations.  The RFC does say
not to establish TCP connections between switches connected to the same
bridged LAN - for efficiency and (very likely) this reason.  

Scott

(**************************************************************************)
 
Date: Fri, 25 Jun 93 16:08:22 EDT
From: [email-masked] (Himanshu C. Shah)
Message-Id: <[email-masked]>
To: [email-masked]
Cc: [email-masked]
In-Reply-To: Larry Samberg's message of Fri, 25 Jun 93 15:42:41 EST <[email-masked]>
Subject: Some general concerns/issues
Status: R

1. I do understand how multiple TIC usage works in a source routing
environment...the problem is:

When the first station attempts to contact the FEP (for example), the whole
CUR-ICR thing happens. If there are two different versions of the same
address out there, it will result in (at least) two ICR coming back. Note
that the originating switch does not realize that they are two different
TICs as opposed to one TIC coming back through two different remote switches.
The originating will choose one of the ICRs as the preferred route and the
other as the capable. My understanding is that it will test and use the
preferred route for each subsequent session to the FEP as long as it responds.
Thus, we end up the situation that "our" customers have not been willing
to accept.
-------
Well, that is easy to fix. You as DLS can do load share for the next
circuit initiation to poke the capable route rather than preferred
one. 

Although, you are right that RFC should provide some more
criteria/suggestion on detecting similar situations.

Himanshu

(**************************************************************************)

Date: Sun, 27 Jun 93 01:01 GMT
From: Robin Layland <[email-masked]>
To: [email-masked]
Subject: Some general concerns/issues
Message-Id: <10930627010101/[email-masked]>
Status: R

1. I do understand how multiple TIC usage works in a source routing
environment...the problem is:
 
When the first station attempts to contact the FEP (for example), the whole
CUR-ICR thing happens. If there are two different versions of the same
address out there, it will result in (at least) two ICR coming back. Note
that the originating switch does not realize that they are two different
TICs as opposed to one TIC coming back through two different remote switches.
The originating will choose one of the ICRs as the preferred route and the
other as the capable. My understanding is that it will test and use the
preferred route for each subsequent session to the FEP as long as it responds.
Thus, we end up the situation that "our" customers have not been willing
to accept.
-------
Well, that is easy to fix. You as DLS can do load share for the next
circuit initiation to poke the capable route rather than preferred
one. 
 
Although, you are right that RFC should provide some more
criteria/suggestion on detecting similar situations.
 
Himanshu
 
I also believe you will get some load balancing because each DLS router will
go through the procedure Himanshu stated (which I agree with). Each router will
make selection, they could all choose the same DLS router to use to reach the
FEP, but they may not. All the traffic from one DLS router will use the same
target DLS router but networks will multiple FEPs will find some DLS routers
will choose one and others will select the second sites( using the second sites
DLS router to reach the second FEP). The result is load balancing at the receive
(FEP) end. Not sure if this is good enoght for what Larry wanted but we
shouldn't try to make DLS solve all the problems.
 
I assume the route selected is the first to come back but I think that is up to
each vendor. 
 
The same load balancing  would happen if there were two routers at a single
FEP's location.
 
Note: I used router but I mean any equipment that implements DLS. Data Link
Switching Switch doesn't sound good.
 
Robin Layland 

(**************************************************************************)

Date: Mon, 28 Jun 93 09:47:51 EDT
From: [email-masked]
To: [email-masked]
Subject:  DLSw common ring number requirement
Status: R

I believe that the requirement that switches use a common DLSw ring
number need apply only to routers connected to the same bridged
lan.  Since DLSw does not have an intermediate forwarding function
on top of TCP, this "parallel bridging path" configuration is the
only way to get a loop and thus the only one to need a common ring
number.  I agree with Scott Barvick that this undesirable configuration
can result in a frame copy going once around the loop in each direction
if the switches on the same LAN are directly TCP connected.

I don't see a problem with two routers across the WAN from each other
having distinct virtual ring numbers.  Each end station sees the other
end station as being on a different LAN segment (i.e., the virtual
ring of the near side router).  The entire end station-to-end station
RIF is never constructed, which has the advantage of relieving the 7-hop
limitation of pre-SRT bridges.  I do believe that the LF bits must be
propagated end-to-end, however, so an end station can know not to
construct frames which exceed the max of an SR bridge on the far side
of the WAN.

Peter Gayek

(**************************************************************************)

From: alan bartky <[email-masked]>
To: [email-masked]
Subject: Proposed Connect/Disconnect Working Group Agenda and Goals.
Date: Tue, 6 Jul 93 10:33:25 PDT
Status: R

Fellow Connect/Disconnect Working Group Members:

It is time to get started on our noble task to resolve connect and disconnect
sequences for Data Link Switching.  This message contains a proposed agenda
and a proposed set of goals for our group.  Please read and comment on ASAP.
We have a lot of work to do in our group and not a lot of time to do it.
Remember that we need your support in order to reach the noble goal
of being able to interoperate SNA and TCP/IP between all of our
companies' products.  So let's get going.

To start the discusion off, here is my proposed agenda and goals for the
group:


Proposed agenda for Connect/Disconnect Working Group of Data Link Switching
(DLSw) Special Interest Group (SIG).

All schedule items indicate the date of completion of the proposed
agenda item.  All deadline dates are a Friday unless otherwise specified.

Date    Item

7/5-9   Agreement on agenda and Working Group Action Items.  Any "ready
        to go" documents should be submitted.  Agreement on goals for 
        document to be submitted/discussed at the next APPN Implementors
        Workshop (AIW).

7/12-16 Initial discussions of RFC 1434.  Questions and Answers between
        parties on differences, advantages and disadvantages between
        techniques.  Formal Submissions/Proposals to be submitted.

7/19-23 Email Discussions of Formal Proposals.  Goal to reach
        consensus on basic technical methods proposed and start of 
        detailed work on working group document for connect/disconnect
        sequences.  Edited Formal Submissions (based on comments) to be
        submitted.

7/26-30 Final discussions on proposals.  Goal to have first draft document
        by Friday.

8/2-6   Discussion/ Comments on first draft of Connect/Disconnect document.
        Technical, Editorial, Content.  New submissions to be additions
        changes to the document.  Goal to have second draft document
        by Friday.

8/9-13  Discussions/Comments on Second Draft Documents.  New submissions 
        at this point should be only to aid in completion or clarification
        of the work in progress.  Goal to have review copy of final Draft 
        by Friday.

8/16-20 Discussions on Final Draft.  Changes to the document should
        be editorial in nature.  Edited final draft ready to go by Friday.

8/23-27 Final Discussions, Document submitted to the AIW.  (Note: This
        is also the week of fall Interop).

8/30-9/3 Initial feedback from the AIW (non connect/disconnect members)
        Answers from Group members to the AIW.  Any discussion within
        working group as needed.  Blatant errors (editing or technical)
        to be corrected by group consensus.  Any final changes to be
        resubmitted to AIW by Friday.  (NOTE:  THIS IS THE TWO WEEK
        FINAL DEADLINE PRIOR TO THE NEXT AIW).

9/6-17  (Two weeks)  Open discussion period, Questions/Answers to rest of
        AIW.  Any proposed changes to the document will be logged and 
        presented in open forum at the AIW.

9/21-23 AIW Meeting, Raleigh NC.


Proposed Goal for Group:

The Goal for the group is to agree upon, and document Connect and Disconnect
methods for interoperation of SNA/LLC, SNA/SDLC and NETBIOS Acess Networks
with TCP/IP Backbone Networks.  It will allow the following connectivity

SNA/LLC  to SNA/LLC
SNA/SDLC to SNA/LLC
SNA/LLC  to SNC/SDLC
SNA/SDLC to SNA/SDLC
NETBIOS  to NETBIOS

NOTE: Generic LLC to LLC is not proposed as a goal.  If it turns out
that it can be easily added, or it it "falls out" as a natural part of
the design, then it will be added.  All four possible SNA combinations are
shown above to illustrate the fact that "any-to-any" SNA connectivity is
the goal.

For SNA Access, the design will allow connectivity for PU1, 2, and 2.1
devices (again if its easy or it falls out, it will be added).

For SNA Access, multiple SAPs will be allowed (other than the default SAP
of 4).  This includes cases where the SAPs are not the same number (e.g.
DSAP = 4, SSAP = 8).

All Connect and Disconnect flows and State machines will be fully documented.
Formal Diagrams, Tables, and example flow diagrams will be used.  Example
flow diagrams will show the entire end-to-end sequence (i.e. both ends and
the middle will be shown).

All work submitted to the group will be considered "public".  Due to the
nature of the group, its' organization, and the nature of the email exploder,
No information can be kept confidential.

All work to be done within the group will be conducted via email using
the Internet.  Phone calls between members should be done only when
absolutely necessary.  Remember this is a public forum, and will work best
when all members can comment, contribute and work together.


Looks like I will personally be on the road this week at one of our
joint technology partners.  I will either check in with my mail or have it
faxed to me.

I look forward to working with you all.  I beleive we have the most
interesting task of all of the working groups, and our collected
work will do great things for our industry.

Alan K. Bartky
Manager of Technology
Sync Research Inc.
[email-masked]
(714)588-2070

P.S.  If you are on the list.  Please send email to the group with the
following information:

Your Name
Your Company
Your Email Address
Your Phone Number
Your Status as an Active or Auditing Member.

Note: I expect "active" members to be active!

(**************************************************************************)

Date: Tue, 6 Jul 93 14:01:10 EDT
Mail-System-Version: <BBN/[email-masked]>
Status: R

All,

>The Goal for the group is to agree upon, and document Connect and
>Disconnect methods for interoperation of SNA/LLC, SNA/SDLC and NETBIOS
>Acess Networks with TCP/IP Backbone Networks.  It will allow the
>following connectivity
>
> SNA/LLC  to SNA/LLC
> SNA/SDLC to SNA/LLC
 >SNA/LLC  to SNC/SDLC
 >SNA/SDLC to SNA/SDLC
>  NETBIOS  to NETBIOS

I also think  that  SNA/QLLC  and derivatives of it  should be
considered on this list.

> SNA/LLC  to SNA/QLLC
> SNA/SDLC to SNA/QLLC

Bernie Brady

(**************************************************************************)